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(54) Generating service detail records 

(57) Generalised service detail records are created 
for a telephony service carried over a packet data net- 
work by monitoring packet network service data, signal- 



ling data and quality ot service data, and combining 
these data to produce the required service detail 
records. 
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Description 

Technical Field 

[0001] mis invention reiates to methods and appara- 
tus for generating service detail records, and to moni- 
toring systems for collecting data for these records from 
a network, such as a packet data network, which is used 
for example to carry multimedia telephony services as 
described in the International Telecommunication Un- 
ion's recommendation H.323orthe Internet Engineering 
Task Force's multimedia data and control architecture 
including the Session Initiation Protocol (SIP). These 
and similar standards define a set of protocols fpr.es- , 
tablishing sessions or calls which may include^pne or 
more users and one or more servers, conriniunicating 
via one or more multimedia channels. '\ 

Background ^ ' , 

[0002] The provision of multimedia communications 
services over a packet data, network (PDN) which may 
not provide quality of service guarantees has. recently 
generated a great deal of, interest due to the success of 
networks based on the internet protocols (TCP/IP). Net- 
work operators are currently trialing multimedia commu- 
nications services over a variety of packet data networks 
such as Internet Protocol ( IP )>. Frame Rela y ( FR) and 
Asynchronous Transfer Mode (ATM). A rriajpr problem 
is to generate service detail records (gener;a!ised call 
data records), in real-tirne or batch-mode, which meas- 
ure the service usage of individual users and the service 
quality that was actually experienced by the user. 



and gatekeepers. 

[OOOS] According to a further aspect of this invention 
there is provided a method of generating generalised 
service detail records for communications carried over 
5 a packet network, comprising the steps of:. 



acquiring packet network service data for the pack- 
ets carrying the communications service; 
acquiring signalling data regarding at least one of 
call control, registration, admissions, bandwidth 
management, call status, address translation and 
intelligent network services; 

acquiring quality of sen/tee data . for the. service 
transrnission level; and 

combining said service data, said signalling data 
^arid said quality of service data to generate gener- 
alised service detail records. 
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[0006] According to another aspect of this invention 
20 . there is provided a method of monitoring a packet data 
sub-network (e.g. ethernet segment) or link (e.g. a T3 
link carrying IP over a Ppint-to-Point Protocol - PPP), 
comprising the steps of: monitoring at a first location sig- 
nalling messages to detect the existence of a call; and 
25 nnonitoring at multiple other Ipcations to identify some 
or all packets associated with the call (in H.323, the Call 
ID can be used to identify all packets associated with a 
.given-calJ),_The-capturedpackets-may-inelude-both-sig- 



Disclosure of Invention 

[0003] According to one aspect of this invention there 
is provided a method of generating generalised service 
detail records for communications (such as telephony) 
carried over a packet network, comprising the steps of; 

- acquiring packet network sen^ice data from packets 
carrying the communications; 
acquiring signalling data from a signalling protocol 
to identify at least one of addressing, configuration, 
status and timing information for endpoints, gate- 
keepers and connections involved in a call; and 
combining said packet service data and said signal- 
ling data to generate service detail records. 

[0004] According to another aspect of this invention 
there is provided a method of discovering the network 
configuration of the endpoints. gatekeepers and their re- 
lationships, for a communications service (such as te- 
lephony) carried by a PDN, by using a passive monitor- 
ing system to capture the signalling messages involved 
in the configuration and negotiation of relationships, ad- 
dressing and resource allocation, between endpoints 



: , nailing data arid data , from nriultinr^edia streams asspci 
30 ated.with the .call. . It may be required for wire-tap appli- 
cations, for example, to use the signalling data to identify 
calls of . interest. and then capture the entire multimedia 
stream. It may be necessary to buffer captured packets 
at each location 'to ensure that all packets associated 
3S with the call could be captured 

[0007] In addition, the packets associated with a con- 
ference call can be correlated togetherlo form a service 
record fqr a conference call. This can be achieved by 
capturing all packets with the same conference ID in H. 
"fo 323, for example. 

[0008] In some cases It may be desirable to monitor 
additional signalling messages, e.g. Signalling System 
No.7 (SS7). protocol messages or Integrated Services 
Digital Network (ISDN) messages, on signalling links in 
45 a switched circuit network (such as the public switched 
telephone network - PSTN) coupled ito said packet data 
network, or Media Gateway Control protocol messages 
(for example MGCP or SGCP) .which are used to control 
the gateway connection between the SQN and the PDN, 
^0 to derive additional monitoring data, and correlate those 
additional monitoring data with, at least some of first 
monitoring data. These can be correlated to the original 
call by using characteristics such as caljing or called par- 
ty numbers to identify the call. 
55 [0009] Thus the invention can involve monitoring the 
control channels used for initiation, modification and ter- 
mination of multimedia sessions, and may include the 
monitoring of the multimedia channels themselves, to 
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provide a service detail record for a session. 
[0010] The invention enables a network operator to 
generate service detail records on a pure PDN. or on a 
hybrid network of interconnected PDNs and switched 
circuit networks (SCNs). There is also described a meth- 
od for automatically discovering the network configura- 
tion infornnation, including addressing and identifying 
the relationships between gatekeepers and endpoints. 

Brief Description of Drawings 

[0011] Methods and apparatus in accordance with 
this invention for generating telephone service detail 
records will now be described, by way of example, with 
reference to the accompanying drawings/ in which: 

f , ■ • ■ - ■ . • . . . 

Figure 1 " shows a distributed monitoring system for 
a PDN carrying multimedia voice' servic- 
es; i --.. . 
' ■ Figure 2 ' shows examples of exterisioris oY'this ar- 
' ^ ' ' ' * chitiscture to correlate data from 'the PDN 
= with signalling data from the SdN;' 
Figure 3 shows the Sequence of messa'ge types 
which can be captured tb construct a Serv- 
ice detail record; 
Figure 4 shows an example of the structure of a 
sen/ice record that could be' constructed 
from the data collected by the monitoring 

■ ■ systenri;' " *• 

Figure 5 " ' i^'^ flow diagram of a process lor mbrtitor- 
' ■ ■ ^ irig'signailirfg nneissages Ve^^^ 

• ' ' -keeper aiito-discovery; " ' ' ' '^ 

Figure 6 is a flow diagram of a process for extVact- 
' * ing' data from gatekeeper ^uto-discovery 
messages; ' 
Figure 7 shows the relationship between the proc- 
esses of Figures 5 and 6; 
' Figure 8 ' illustrates a failure mode which can affect 
- the gatekeeper auto-discovery proce- 
dure; 

Figure 9 is a flow diagram of a process for rrionitor- 
^' = ing signalling messiages related tb regis- 

' ' • tratiori of endpoints with gatekeepers; 

Figure 1 0 is a flow diagram of a process for exlract- 
' ' ing data from endpoint registration mes- 

■sages; 

Figure ^^' ' is a flow diagram of a process for extract- 
ing data from endpoint 'uni-egistration 
' " ' messages; 
Figure 12 illustrates poteritially anomalous registra- 
' " tion of endpoints with a gatekeeper in a 
different sub-net; 
■ Figure f 3 ' illustrates potentially anomalous load im- 
' balance between two gatekeepers in a 
sub-net; 

Figure 14 * is a flow diagram of a process for monitor- 
ing call signalling channels; 
Figure 15 is a flow diagram of a process for monitor- 



ing call signalling messages; 

Figure 16 is a flow diagram of a process for monitor- 
ing control channels; and 

Figure 17 is a flow diagram of a process for monitor- 
5 ing call signalling channels having dy- 

namic TSAP identifiers. 

Best Mode for Carnring Out the Invention. & Industrial 
Applicability 

10 

[0012] The distributed monitoring system shown in 
the drawings has the capability to collect data from a 
combined PDN and SCN carrying multimedia sen/ices, 
•correlate these data in real-time, and provide a real-time 
IS ' view 6f services on the network. These data can be used 
foV applications such as troubleshooting, surveillarice, 
seburity!' network' planning, provision of accounting in- 
formation to customers, fraud detection, billing and ac- 
quisition of marketing information. 
20 [0013] Referring to Figure 1, the probes shown are 
part of the distributed monitoring system, and are pas- 
- bive link mohitofihg devices (using techniques similar to 
" those' in existing* pfbtbcor analysers for' example). The 
' distributed nfibri'itorirtg system iis constructed frbm the 
25 ' probes and' standard ' corn put er and communications 
components, With special-purpose software which pro- 
vides the applicktibrisdes6ribed above. A principal func- 
tion of this software is to correlate data from different 
probes to jprovide a record or real-time trace of calls, 
30 • ' tmhsactibhs and other services as they occur on the net- 
""work. "rtie'Hewlett-Packar is ap ex- 

arriple of a disiributW passive monitoring system which 
" could be used, to implement parts* of the system de- 
scribed abbv6. 

35 [0014] A Data Management Infrastructure (DMI) col- 
lects the data from the probes and processes \he data 
to produce sen/ice detail records. The DMI may consist 
of software running on one or more computers, and the 
•processing of the diata and Its storage'may be distributed 

40 ■ across these computers. The service detail record gen- 
eration process may be split between the probes and 
the DMI. The probes may generate partial service detail 
records by correlating all the iriformation available on 
that probe about a" particular session, arid forwarding 

45 those partial records tb the DMI. The DMI is then re- 
sporisible for correlation of partial service detail records 
from different probes to form the final service detail 
records. Aiternatively the probes' cari forward uncorre- 
lat'ed data to the DMI, and the DMI is then responsible 

50 for generatirig the complete service detail records. In 
both cases the DMI is also responsible for the storage 
of the service detail records and for providing interfaces 
for application programs to analyse the service detail 
records. This aspect of the DMI may be implemented 

55 using data warehousing technology. 

[0015] An example of a monitoring system architec- 
ture is given in Figure 2. This" shows probes monitoring 
the PDN, SS7 network and the ISDN. The SS7 probes 
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could be for example from the Hewlett-Packard 
access? system. The ISDN primary rate access probes 
could for example be constructed using the same tech- 
niques as in existing protocol analysers (such as the 
Hewlett-Packard 37900D Signalling Test Set). The PDN 
probes could be constructed from Hewlett-Packard 
4986/7 or J3457/8 LanProbes for example. 
[0016] The distributed monitoring system is arranged 
to correlate real-time data from any combination of 
these probes. This includes, for example, signalling data 
from the SS7 links, signalling from the ISDN links (e.g. 
the D-channel for narrowband ISDN), the signalling data 
for the multimedia service from the PDN. and the multi- 
media stream data (e.g. data indicating packet loss! la- 
tency or jitter). It may also includethecapture of trie en- 
tire multirnedia stream for applications like wire!tapping 
or troubleshooting. v . 

[001 7] For convenience the invention is described pri- 
nnarily with reference tothe H.323 recommendation, us- 
ing IP as the PDN, and optionally connected.to one or 
more SCNs using narrowband ISDN arid/or SS7 signal- 
ling with trunk connections; However, it should be un- 
derstood that this termi'noiogy is to be taken as including 
vyithin its scope Analogous functionality, whether or not 
they are customarily identified by the terms used in 
these standard recommendations. " ' 

AUTO-DISCbvERY PROCESS 



[0018] The PDN is continuously monitored for pack- 
ets that provide configuration information on H.i323 end- 
points and gatekeepers. . These packets may be cap- 
tured to create and maintain a database (the network 
discovery database) which gives configuration informa- 
tion/addressing information and relationships between 
the ehdpoints and gatekeepers. The network discovery 
' database may also take data from additional sburces to 
supplement or verify the captured data. Any discrepan- 
cies between the discovered data and the data from oth- 
er sources should be used to generate ah alarm to the 
network operator indicating a possible network configu- 
ration problem. The details of the data captured are de- 
scribed in the following paragraphs. 
[0019] A type of transaction which is tracked by the 
monitoring system is the gatekeeper discovery process. 
This is used by an endpoint to automatically find a gate- 
keeper which will provide service to it. The monitoring 
system uses the data captured from the sequence of 
messages between the endpoint and the gatekeeper, to 
identify endpoints and gatekeepers and to build a data- 
base of the relationships between endpoints and gate- 
keepers. The database stores information derived from 
the captured data which identifies the endpoint and 
gatekeeper. This includes the network addresses and 
port numbers. The monitoring system monitors contin- 
uously for endpoint discovery attempts, to maintain an 
accurate database of the network configuration. This 
monitoring process is described in more detail below 



with reference to Figures 5 to 8. 

[0020] The endpoint may go through a registration 
process with its gatekeeper. This process may be re- 
peated periodically if the registration has a finite lifetime. 
5 The monitoring system monitors the network continu- 
ously for packets involved in the registration process. 
The monitoring system captures the relevant packets 
and uses the data relating to the endpoint and gatekeep- 
er to update and add information to the database. This 
10 typically includes any transport addresses (transport ad- 
dress = (Network address, Transport layer Service Ac- 
cess Point (TSAP) or port number)), any alias address- 
es and any other addressing or configuration informa- 
tion associated with the endpoint or gatekeeper. 
15 [0021] Endpoints may also request from a gatekeeper 
location information for an endpoint for which it has the 
J'^® monitoring system will continuously monitor 
for the pxchange of packets associated with this location 
process and capture data from, the relevant packets. 
^0 i;his data can be used to update or add information .to 
the network discovery database that identifies the rela- 
tionship betweeri aliases, transport addresses and any 
other addressing or configuration information. This'may 
include information which identifies how to connect to a 
25 destination on the SCN (e.g. E.I 64 addresses)., More 
details of monitoring of the registration process are giv- 
en below with. reference to Figures 9 to 13. 

[D022]__^cqess4okens may-be used-to enable an-end= — 

ppint to hide its transport adqiress frorn the endpoint to 
30 which it ip, establishing comrriuriicatipn* The monitoring 
system vyill cprttinuously monitor the network to captu re 
packets that are used in the process of distributing ac- 
cess tokens to endpoints. The captured data is used to 
add to or update information , in the network database 
35 indicating the association between an' access token and 
an endpoint. 

GENERATION OF SERVICE RECORDS 

40 [0023] This section lists the types of fields in service 
records, and describes how the distributed monitoring 
system could provide the required data. A sen^ice record 
is generated for each instance of the usage.of a specific 
service. This is a generalisation of a call record, which 

^5 is generated by current switches. A service is normally 
defined from the perspective of the user. The service 
may actually involve a number of calls or transactions, 
for example. In the case where only the PDN is being 
monitored, these service records include data from the 

50 signalling between any combination of gateways, gate- 
keepers, terminals and multi-point controllers; and data 
from the multimedia streams controlled by this signal- 
ling. In the case where the SCNs connected to the PDN 
are being morirtored, the service record will also include 

ss data from the signalling data on the SCN collected from 
the probes connected to the SCN. The network discov- 
ery database may be used in constructing the service 
records to fill any address or configuration information 
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which is not available directly from the packets involved 
in the call. 

[0024] Figure 3 shows an example of the sequence 
of packets which may be captured at different levels in 
the overall stack of protocols (such as Q.931 , H.245 and 
an unreliable datagram protocol - UDP) to provide a 
service detail record. Figure 4 illustrates how the infor- 
mation from these different parts of the overall transac- 
tion can be used to contribute to different respective 
parts of a service detail record. 

1 . Calling Party Information. 

' [0025] This includes any information whichcan be de- 
rived about the calling party from the signalling data 

fTowing on the PDN, arid is therefore available to the link 
monitoring probes. Typical information includes: calling 

-party nUmber; any ISDN sub-addressing informatibn; 
calling party namis; network addresses; TSAP or port 
numbers; alias' addresses; and any numbers Or ad- 

' dresses related to billing. This information ban be de- 
rived from the'sequence of messages used to setup a 
calL In the H-323 recortimendation, this can be achieved 
by extracting the relevant fields from the Q.931 messag- 
es used in setting ijp the call (set-up. call proceeding, 
alerting, connect for example). In the cases where one 
or more gatekeepers are involved the admission signal- 
ling (H.225 ARQ and ACF messages for example) be- 
tween' gatekeeper and endpoint lis capturied to identify 
"the Idgical chanhet br cali'signallirlg; The logical chan- 
nel is typlcaily identified using the transport 'address. 
[0026] ' Additional inf drmation nhay be deriv^pd f rorri c'all 
setup rhessages on the ISDN D channel^ of an intercon- 
nected SCN, at either the originating or terminating ehd 
or both; and/or from call setup messages on any of the 
SS7 links of the SCKl. Additional information may also 
be derived from any intelligent network service messag- 
es that flow over the SS7 links as part of the specific 
service usage. 

2. Called Party Information. 

[0027] As for calling party information, but replace 
calling party by called party. 

3. Information on each party in" a conference. ^ 

• [0028] The equivalent data to the calling party infor- 
mation for each party iri a conference, with additional 
information on the conference objective (join confer- 
ence, create conference or invite for exarriple) arid a 
means to identify the conference (Conference jP for ex- 
ample). 

4. Network Routing and Logical Channel Information. 

[0029] This'may include any information on the net- 
work resources which were used to provide this specific 



service usage. The following are examples of data 
which might be provided: 

logical channels associated with the call and their 

5 identifiers, 

the requested media, codecs (coder/decoders), 
service quality and bandwidth for each channel, 
the negotiated media, codecs, sen/ice quality and 
bandwidth for each channel, . 

70 - any other performance or configuration data on the 
* channels which are requested or established during 
the call or conference. 

Each of these uses Is time-stamped, and the sequence 

?5 * arid nature of the use indicated. These data can be ob- 
tained'in a similar way as was described for itern 1 above 
frorri the capture of packets carrying signalling informa- 
tion. More specifically the logical channels can be .iden- 
tified by using the fields within an OpenLogicalCharinel 

20 ' Structure within certain messages defined in hi. 323 and 
/associated recommendations. Subsequent messages 
which control the logical channels are also monitored 
and any changes in channel' configuration can be time 
^ stamped and added to the service record. 

25 [0030] A frnportant addition af set of inf ornriat ion is the 
measured quality of service and bandwidth usage, on 
each of the logical channels set-up as part of the call. 
This will typically include packet loss rates, latency and 
jitter measurements which are made over selected in- 

30 tervals by capturing packets from the logical cJ^annels 
"and extracting the relevant fiel^^ ' . 

5. S'upplementairy Services Information. ^ 

35 [0031] This m^y include any inform'ation^on . supple- 
mentary services used for this specific servicp usage. 
The following are some examples of the data vyhich rnay 
be provided: \ ^ . , . . 

40 - call forwarding indication ahd'address information; 
- interactive voice response ihformatibn on, the use 
^ of intelligent peripherals; , . 

800 number services; 

any custom services that may be inyoke^d during the 
45 'call or conference. , ... 

This information includes time-stamps, duration and the 
nature of the use. These data can be obtained iri a sim- 
ilar way as was described for item 'l above. . 
50 ' 

'6. Service Status and Termination Information. 

[0032] This may include time-stamped information on 
the initiation of the service, time-stamped information on 
55 any status changes occurring dijring service and time- 
stamped Information on the termination of the service. 
The termination information should include the reasons 
for termination. 
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[0033] These data can be obtained in a similar way 
as was described for item 1 above. In particular, the H. 
245 endSessionCommand message and the Q.931 call 
termination messages, the call clearing messages on 
the SS7 links and the ISDN D channels can provide de- s 
tails on the reasons for call termination. 

7. Additional Service Quality Information. 

[0034] The service quality information provided is de- w 
pendent on the service indicated in the service type field. 
The following gives some examples of what can be pro- 
vided for specific services. ' 
[0035]. Voice quality is mainly indicated by the;bit error 
rale, jitter and delay. These parameters can b^e meas- is 
ured using a passive monitoring system and monitoring 
at two points in the network. Signalling information can 
be used to identify the logical channels orn the.PDN, the 
ISDN B channels or the time slots on SCN trunks, that 
are carrying the voice signals. The bit streams (rom each 20 
of the channels or trunk lime slots identified can be cprri- 
pared to derive the delay, jitter and bit error rate caused 
by the internriediate networks. 

8. Service Usage Information. ' 2s 



[0036] The type of usage data provided by the distrib- 

u ted monitoring system depends on the specific service . 

Some examples follow. 

[0037] Voice, video and fax services i-equire call' du- ' 30 
ration and used bandwidth. ' 
[0038] The d^ta oViented services require data such 
>s total bits, frarhes arid'packets in eiach ciireptibn. This 
rnay be provided for regulartinrie intervals for the dura- 
tion pf the service. It may also be broken down into a 
traffic matrix, where the data protocol has additional ad- 
' dressing information (such as IP addresses).' The data 
are' obtained in a similar way as is described for Item 1 
above. 



35 
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9- Security Iriformation. ' . 

[0039] A particular instance of service usage may be 
an attempt to' pbtain unauthorised access to resources. 
The, service record includes information which may in- 4S 
dicate this type of behaviour. This may include informa- 
tion about the duration of calL the way the call was ter- 
minated and details of the service used. 
[0040] An example would be where there are repeat- 
ed failed attempts to gain access to different resources, so 

REAL-TIME UPDATES ON SERVICE USE 

[0041] The data that populates the service records 
described in the previous section can be collected in re- ss 
al-time from the monitoring probes. These data can be 
provided in real-time on remotely connected computers, 
as they become available. A user of the distributed mon- 



itoring system can apply filtering criteria on any of the 
information described in the previous section, to select 
those instances of service use for which real-time up- 
dates are required. 

WIRE-TAP CAPABILITY 

[0042] Any of the data extracted from the signalling 
messages can be used to match criteria set by the user 
of the monitoring system and trigger some or all of the 
logical channels to be captured in their entirety. This 
technique can be used to provide a wire-tap capability, 

. which would allow real-time copies of the media streams 
to be routed through the monitoririg system to a third 

. party, or stored'for analysis. The filtering could also, be 
prp characteristics in the media stream (for example, a 
specific spoken word in an audio stream) which, if 
matched, would trigger the capture of all the service 
record Information from the signalling messages,' as de- 
scribed earlier. 

APPLICATIONS 

[p043] The following applications can be implement- 
ed using the data from the service records described 
above or the real-time service updates. Data from other 
sources may be used to enhance the effectiveness of 
-these-appJicatlpns . — 



A. Quality pf Service and Service Level Agreements. 

[0044] The service records described above can be 
used to provide service quality information on selected 
customer's service. This can be used to track conform- 
ance to sen/ice level agreements, and be provided to 
the customer as an additional service. It can be provided 
as periodic reports, or in real-time usipg the real-time 
updates described above. 

B. Surveillance and troubleshooting for Network 
.Operations. 

[0045] The service records and real-time updates can 
be used to identify service or network faults. The infor- 
mation can also be used to tr;oubleshoot the faults. 

C. Fraud Detection. 

[0046].. The service records and real-time updates can 
be used to identify potential fraudulent use of the iiet- 
work or service. Indications mayjnclude excessive use 
of high value services, unusual call termiriation behav- 
iour and repeated failures to gain access to. a service. 
The distributed monitoring system may be used to track 
the service usage of potential high-risk users in real- 
time. 
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D. Security and Hacking Detection 

[CX)47] Potential security threats can be identified by 
repeated failures to gain access to a service. They also 
may be indicated by successful access to sensitive serv- 
ices, such as maintenance ports on customer premises 
equipment (CPE). This type of data Is available from the 
service records and the real-time updates. 

E. Billing Data 

[0048] The service records can be used as a basis for 
billing which is dependent on any of the fields in the serv- 
• ice record. This" allows, for example, billing to be based 
on the actual sen/ice quality delivered. It also enables 
billing to reflect th'e'nature and generation of the usage 
' of resources on the network, such as intelligent periph- 
■ erals and databases. The billing data could bei made 
available'inVeal-time. *, 

R Customer Accounting Data 

[0049] The detailed service usage information in the 
service records can be provided to customers for use in 
their internal accounting. This includes the traffic matrix 
information for packet and frame based protocols, which 
the system derives from the B and D ISDN channels. 

G. Customer and Telecom Operator Network Planning 

[0050] The service records can provide detailed infor- 
mation on the use of network resources which can be 
provided to network plann ihg departments within the op- 
erator and the customer. 

H. Wire-tap ' 

[0051] The wire-tap capability described above can 
be used to provide wire tap services to authorized third 
parties, and potentially as a trouble shooting tool. 

MONITORING OF H.323 GATEKEEPER oisCOVERY 
TRANSACTIONS 

'[0052] As' noted above, the gatekeeper discovery 
process is the process an endpoint uses to determine 
which H-323 gatekeeper to register with. The process 
can be performed manually or automatically. Manual 
discovery relies on information provided independently 
tothe endpoint, and analysis of the endpoint registration 
procedure in this case can be u^ed to identify inconsist- 
encies in the available informatiori. 
[0053]' The discovery process starts when an end- 
point multica^ts a Gatekeeper Request message (GRQ) 
to a predetermined address (Discovery Multicast Ad- 
dress). On receipt of such a message a gatekeeper can 
either accept (Gatekeeper Confirmation message - 
GCF) or reject (Gatekeeper Reject message - GRJ) the 



request. 

[0054] If several gatekeepers responds positively with 
GCF messages to the GRQ message, the endpoint is 
free to choose among them arbitrarily. In this case, anal- 

5 ysis of the choice of gatekeeper can usefully reveal if a 
suitable choice was made, or it can be used to verify 
assignment policies set by system managers. Analysis 
of the list of alternative gatekeepers is also worthwhile 
since it can provide information about network redun- 

10 dancy. 

[0055] Rejection messages and no-answers to GRQ 
messages are valuable since they enable verification of 
assignment policies as well as investigation of problems 
related to multicasting. " . 

IS [OOSSi Monitoring of the gatekeeper auto-discovery 
procedure is in this embodiment split into two process- 
" es: ^ "[ ' 

Dispatcher process (Figure 5); and 
20 : SigProcessing process (Figure 6). 

[0057] Referring to Figure' 5,. the Dispatcher process 
collects all the CaRQ. GCF ahd'GRJ signalling messages 
detected by the link monitoring probes and' determines 

2S the endpoint to which each refers. Then, as illustrated 
in Figure 7, the messages are dispatched to an appro- 
priate SigProcessing finite statiB machine (FSM) proc- 
ess which coordinates assembly of the data necessary 
to assess the gatekeeper autondiscovery procedure in 

30 relation to a specific endpoint. there need be only^a sin- 
gle instarice of the Dispatcher process, but several Sig- 
Processing processes can be active at the same time. 
[0058] Referring ' to the state definition language 
(SDL) chart in Figure '6, the SigProcessing process con- 

35 sists of an FSM which keeps track of the'evolutioh of the 
gatekeeper auto-discovery process for a specific. end- 
point For the sake of clarity and simplicity, the chart has 
' been designed with the assumption that the monitoring 
s^'stem is installed before endpoints start the gatekeep- 

40 er discovery process. In practice some endpoints might 
already be in the middle of the gatekeeper, discovery 
process when the monitoring system is first installed. In 
this case a GCF or GRJ message is the first Xo be re- 
ceived in respect of such an endpoint, andthe behaviour 

45 "bf the FSM, shown 1n Figure 6 may be determined at the 
discretion of the system operator: Incomplete informa- 
tion may be collected or. altematively, the signalling in- 
formation involved may be discarded. 
[0059] In relation to an endpoint. the measurements 

50 that can be collected and used to assess the overall 
gatekeeper auto-dlscovery process include: 

list of available gatekeepers (derived from GCF 
messages time-stamped and ordered); 
55 - list of gatekeepers that rejected the GRQ request 
(derived from GRJ messages time-stamped and or- 
dered); 

list of altematlve gatekeepers; 
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alarms (no answers to GRQ messages: GRQ re- 
transmissions too quick or too numerous); 
warnings (RIP messages, i.e. gatekeepers too slow 
to answer). 

The 1st GRQ and the GCF or GRJ can be time-stamped 
and statistics about response times can be derived. 
[0060] Similar statistics can be also obtained for dis- 
covery process performance from the point of view of 
gatekeepers. 

[0061] The case of endpoints that do not receive any 
. answertotheir GRQscanbe worthy of study. Two caus- 
es can be identified for this behaviour: GRQs rriay be 
. sent to a multicast address differerit from the predeter- 
mined Discovery. Multicast Address, .revealing -mis-con- 
figuration at the endpoint; or, as shown in.Figure 8,.there 
may be configuration problems within a router causing 
the router to fail to forward multicast requests frorp one 
sub-net to another. Pleafly .there is also the!,possibilit^ . 
of network disruption that occurred at the tirrie an end- 
point initiated the gatekeeper discovery procedure.' For 
this reason it isjmportant to keep a record of timing in- 
formation since jt allpws later correlation with other net- 
work events. 

[0062] The signalling messages involved in the gate- 
keeper discovery procedure and, in particular, thfe fields 
carrying key data for monitoring this procedure, are 
summarized below. This summary focu ses on the efi- 
sential fields, though more data can.be extracted if .de- ^ 
sired from the. signalling messages in order to .provide 
more complete information about the.overall gatekeeper 
discovery process. / ^ \ ' . ^ 



Gatekeeper Request (GRQ) 
[0063] 



10 



IS 



reqSeqNum. This allows correlation with subse- 
quent signalling (GCF and GRJ messages) originat- 
ed in response to this request. 40 
rasAddress. Transport address of the endpoint 
(Registration, Admission and Status - RAS - chan- 
nel). 

endpointType. This identifies the type of eridpoint 
(useful for consistency checks). as 
gatekeeperjdentlfier. This should be empty. Other- 
wise, it contains the identifier of the gatekeeper the 
endpoint isjnterested in registering with. , 



so 



Gatekeeper Confirmation fGCF) 
[0064] 



reqSeqNum. Must be the same as in the corre- 
sponding GRQ message. ss 
gatekeeperldentifier. This identifies the gatekeeper 
that is sending the GCF. 

rasAddress. Transport address used by the gate- 



keeper for registration and status messages. 
alternateGatekeeper. Prioritised sequence of alter- 
. native gatekeepers and related RAS addresses. 

Gatekeeper Relect (GRJ) 

[0065] 

reqSeqNum. Must be the same as in the corre- 
sponding GRQ message. 

- . gatekeeperldentifier. This identifies the gatekeeper 
that is sending the, GRJ. 

rejectReason. Cause code related to this rejection. 

- alternateGatekeeper. Prioritised sequence of alter- 
. native gatekeepers and related RAS addresses.. 

r , altGKisPermanent. This indicates, if future , RAS 
; . ^messages should be redirected tO;the alternative 
gatekeepers or not. 



20 MONITORING OF ENDPOiNT REGISTRATION 



.[0066] , . The endpoint registration procedure, is comple- 
mentary XoXhe gatekeeper discovery procedure, and en- 
ables an endpoint.to join a "zone" nrianaged by a chosen 
gatekeeper and inform the gatekeeper of its Transport 
Address and Alias addressees. Monitoring of this proce- 
dure .enables the zone managed by one gatekeeper to 
_be4ndependentlypdetei:minedHt-also-allovvs-correlat 
of ,the information gathered, during monitoring, of the 
gateKeeper discoyery procedure in. order to assess the 
: chpic^, of specific gatekeeper by an endpoint. 
[0067] Registration is mandatory and must be done 
before any call is attempted. Furthermore, it may^pccur 
periodically according to the gatekeeper's policy it 
might happen that the frequency of the registration proc- 
ess is very low and that therefore signalling related to 
the registration process is rarely captured. As an alter- 
native monitoring of the admission procedure (e.g. ac- 
cording to recommendation H.225) cari be used to ere- 
; ate similar information to that gathered through monitor- 
ing qf the registration process, . , . 
[0068] The ^registration process involves only three 
signalling messages; usually it follows the gatekeeper 
discovery process. An endpoint sends a Registration 
Request message (RRQ) to a gatekeeper, using the . 
gatekeeper's RAS address, which is, known from the 
previous:.gatekeeper discovery process. On receipt of 
.such a. message the gatekeeper .can either accept, or 
reject the request and replies with a Registration Con- 
firmation (RCF) or Registration Reje^ct (RRJ) message, 
respectively. Reasons for rejection of the registration 
can include ambiguous registrations and security is- 
sues. 

[0069] The registration process can be periodically re- 
peated since each registration may have a finite life. 
Moreover, updates in an endpolnfs Transport Address- 
es and/or Alias addresses are notified through new reg- 
istrations 
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[0070] Closely related to the registration process is 
the unregistration process, by which and endpoint and 
a gatekeeper cancel the relationship which exists be- 
tween them. Either an endpoint or a gatekeeper can in- 
itiate it. It also consists of three messages. The Unreg- 
ister Request (URQ) message triggers the procedure. If 
initiated by a gatekeeper the endpoint has to acknowl- 
edge it by replying with an Unregister Confirmation 
(UCF) message. If initiated by an endpoint the gate- 
keeper might reply with an Unregister Reject message 
(URJ). This might be due to the fact that the endpoint 
was not in fact previously registeriad with this gatekeep- 
er The unregistration procedure may or may not be in- 
voked before a re-registration. . 
[0071] A gatekeeper must keep a one-to-one map- 
ping between Transport and Alias addresses:'" Changes 

■ of both Transport and Alias addresses at once ban occur 
and they should be preceded by use of the uhregistra- 
tion procedure. ' ' 

[0072] Monitoring of the registration procedure is val- 
uable'- for several" reasons. It can provide ifSformatfon 
needed to define zones and provide a mapping between 
Transport Addresses and AliaseSs. Fdrtherniorei se^cUfi- 
ty policies can be monitored and verified and, evehtuhl- 
ly» fraud or fraud attempts discovered. Gatekeeper load 
balance can also be usefully analysed. Final ly; mapping 
of thia endpoints that belong to a zone in conjunction with 

' depiction of the physical represehtatroh of the network 
topology (e.g. derived using 'auto-discoS/ery facilities in 

'the Hewlett-Packard ■dpenVtew'netw^^ 
tool) can be extreni'ely^ujs^ful to ideHtify"'n6twbfk p^^^ 
iems such as 'cor^ectivity' bottlenecks or' unsuitable 
gatekeeper chdi6es.- ' 

[0073] As mentioned earlier, the adnriission procedure 
can be used slrnilarly to the registration procedure'fo 
generate data about the zone discovery. In this case, 
algorithms similar to thos'e described herein can be used 
by replacing RRQ vvith ARQ, RCF with AC F and RRJ 
with ARJ, respectively. " ' ' ' ' 
[0074] Processing of the registraition and unregistra- 
tion signalliiig is sjDiit into two. A first Dispatcher process 
(shown in Figure 9) recognises if an^^ of the reigistration 
or unregistratibn messages that are captured refers to 
any endpoint already registered or in the process of dd- 
ing so. As illustrated by reference again to Figure 7, the 
Dispatcher process" also dispatches the signalling riries- 
sage to' one ot two SigProcessing processes which ex- 
tract the data necessiary for zone discovery. SDL charts 
for these two processes'are shown' in Figure 10 (regis- 
tration) 'and Figure 11 (unregistratibn), respei^tively. 
[0075] The measurements that' can be collected in 
this way and used to generate data about zones include: 

endpoint < — gatekeeper relationship (dynamic re- 
lationship); 

Transport Address < — ^ Alias Address correspond- 
*ence (dynamic relationship); 
- ' gatekeeper load balance; 



alarms (no answers to request messages); 
warnings (RIP messages, i.e. gatekeepers too slow 
to answer); 

mapping of a zone over the physical network topol- 
5 ogy; 

assessment of the choice by endpoints of the gate- 
keeper to register with; 

analysis of rejections of registration and unregistra- 
tion attempts. 

10 

The endpoint-gatekeeper relationship is a temporal re- 
lationship which has a related start and end time. Simi- 
-lai^ly.'the identification of endpoints through Alias and 
' Transport Addresses is dynamic and it must be associ- 
15 ated with timestamps. Consistency checks should pref- 
erably'bfe'carried out to verify that a unique mapping ex- 
ists' bi^tweeh ah Alias Address and theVelated transport 
Address^^ '' 

' [0076y- -It is jDOSsible to highlight cases of" endpoints 
20 that'do hb'l receive ariy'an'swer to RRQ or URQ mes- 
sages'. This riii'gh't be due, for example, to the use of an 
ihtdrre'dt ^gatekeeper hAS ' address, the information 
gathferied about the registration prociedure can be Used 
to assess the choice of gatekeeper with which endpoints 
25 register and. ultimately, to determine abnormal configu- 
rations. ' ■■ I. ■ : " 

[0077]- Mbreov6r/it is useful to map zones relative to 
physical network topologies.' For example. FJgure 12 
shows two sub-nets, eadh with a gatekeeper and sev- 

30 eHdpbints. ^>lor6 specifically two endpoints in the 
'''3'ub-rifet''A'aire9e^isfeyed with a gatekeeper GKb that is 
"asbociate'd-'witfT'ahbth'er sub-net sub-net B. this hnay 
be a desirable behaviour justified by gatekeeper load 
balancing policies. However, it might also be anomalous 

35 behaviour. ' . . - 

[0078] With regard to gatekeeper load balance. Fig- 
ure 1 3 shows schematically the traffic between the end- 
points and the gatekeepers on the same sub-net. Clear- 
ly load irhbalance exists'between the two gatekeepers. 

40 -As in the previous case, this may be a desirable* behav- 
iour. But it might also reveal the existence of a situation 
that does not match the desired policy put in place by 
the system administrator.' 

[0079] Rejection messages, such as RRJ or URJ, can 
45 be useful to highlight either configuration or security re- 
lated problems, e.g. fraud attempts. 
[0080]' * The signalling messages involved in the regis- 
tration and unregistration procedure and, in particular, 
the fields that carry the key data for the monitoring of 
50 these procedures, are summarized below: 

Registration Request (RRQ) 

[0081] 

55 

requestSeqNum. Monotonically increasing number 
unique to the sender 

discovery Complete. Set to TRUE if the registration 
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follows the gatekeeper discovery process. It could 
happen that when a registration ages, the gate- 
keeper discovery has to be Invoked before attempt- 
ing a new registration. This is one possible reason 
for rejecting an RRQ or ARQ. 
callSignalAddress. Call signalling address for the 
endpoint. 

rasAddress. Transport address of the endpoint 
(RAS channel). 

ternninalType. This identifies the type of endpoint 
(useful for consistency checks). 
- terminafAlias. This should be ennpty. Otherwise, it 
contairis a list of Aliases to identify the endpoint. 
Gatekeeperl^entifier The gatekeeper with which 
the terminal wishes to register 
alternateEndpoints. A sequence of endpoint alter- 
natives for CallSignallingAddress, rasAddress, ter- 
minalType, or 'terminalAlias.' 

Registration Confirnnation (RCF) 

[0082] 

requestSeqNum. Sam^ value as for the RRQ.^ 
callSignalAddress. Transport Addresses for , H. 
255.0 signalling. 

terminalAiias. A list of Alias Addresses assigned by 
the gatekeeper by which other terminals identify the 



endpoint. 

reason. Reason for the unregistration initiated by 
the gatekeeper 

Unregistration Confirmation (UCF) 

[0085] 

requestSeqNum. Same value as for the URQ. 
Unregistration Reject (URJ) 
[0088] 

requestSeqNum. Same value as for the URQ. 

- , rejectReason, The reason for the rejection of the 

unregistration. ./ . . 

- ^^ alternateGalekeeper Sequence of prioritised alter- 

, native gatekeepers with which to retry requests, 
allGKisPermanent. True or False, indicates if all 
subsequent messages are to be redirected to the 
alternative gatekeepers. 



EXAMPLE 1 - Two Endpoints Communicating 
^5 Directly without a Gatel<eeper 

[0087] (n thjs first example it is assumed that: 
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20 



endpoint. 

- Gatekeeperldentifier the gatekeeper that , has ac- 
cepted the endpoint registration. 
timeToLive..puratiori of the validity of the registra- 
tion. 

preGrantedARQ. Special pre-granted permission 
to make phone calls. 

Registration Reiect (RRJ) 

[0083] 

requestSeqNurn. Same value as for the RRQ. 
rejectReason. The reason for the rejection of the 
registration. 

Gatekeeperldentifier The gatekeeper that has re- 
jected the endpoint registration. 

- altemateGatekeeper Sequence of prbritised alter- 
native gatekeepers with which to retry requests. 

- altGKisPermanent. True or False! Indicates if all 
subsequent messages are to be redirected to the 
alternative gatekeepers. 

Unregistration Request (URQ) 

[0084] 

requestSeqNum. Monotonically increasing number 
unique to the sender 

callSignalAddress. Call signalling address for the 
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... the underlying, network is- an , IP network, .TCP is 
,. use^^ to provide, reliable connections and UDP is 
used to provide unreliable connections; . 
the two endpoints communicate directly without the 
use of a gatekeeper - this simplifies the process be- 
cause the Call Signalling Channel uses a "well- 
. known" TSAP identifier (specified in recommenda- 
tion H.225); the case where the Call Signalling 
Channel is identified through an interaction with a 
gatekeeper is described in Example 2 below; 
there are only two endpjoints, which initiate one or 
more audio or video connections using Real Time 
Protocol (RTP): 
the call is not modified during the session, for ex- 
ample by adding new participants or requesting 
changes in bandwidth; 

the. Call Signalling Channel remains open for the 
duration of the session, and a, RELEASE COM- 
PLETE message is used to terminate the session. 

[0088] , The finite state nriachine processes required to 
monitor this type of session are as follpws: 

1. Call Signalling Channel FSM (see Figure .14) 

[0089] This monitors all links continuously looking for 
a reliable-connection setup (for example, the SYN of a 
TCP connection) using the well-known TSAP identifier 
for the Call Signalling Channel. In response to a Call 
Signalling Channel being established, this process inl-* 
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tiates a new Call Signalling Message FSM (CSM-FSM 
- see item 2 below) to monitor the Channel and passes 
to it the transport addresses of the two endpoints. 

2. Call Signalling Message FSM (see Figure 15) 

[0090] This is initiated to monitor a specific Call Sig- 
nalling Channel, and is terminated when the reliable 
connection is terminated for that Channel (for example, 
by the FYN of the TCP connection), it continuously mon- 
itors the Channel for signalling messages. A SETUP 
message indicates the start of a new call, and causes 
the process to create a new service detail record (SDR) 
for the call. The call identifier is used to uniquely identity 
the service detail record for the duration of the call, and 
to identify subsequent call signalling messages. The 

* service detail record is populated with a time stamp, and 
any useful fields from the SETUP message. 

'[OOsil] The CONNECT message sent from the called 
end point norrfially calories the transport addresses to be 
' used for the 'H. 245' Control Channel. In resfDorise to this 
message an h;245 Control Channel FSM (HCC-FSM - 
see item 3 below) is started, to monitor the H.245 sig- 
nalling for the session. The service detail record is pop- 
ulated with an additional time stamp if required* and any 
of the useful fields from the CONNECT nriessage. 
[0092] A RELEASE COMPLETE message indicates 
the term! nation' of the session'.' The service detail record 
is updated with any relevant data and time stamps, and 
•'then closed, the H/2'45 Controf'^Chahnef FSM mbnitor- 
Mng the H. '245 signalling islerrhinated. Hiowever, moni- 
toring for subsequent signalling messages is continued 
in order to capture further calls betweerl the two end- 
points. ' ' ' 
[0093] " The main paths in this FSM are shown in Fig- 
ure 15; however inthe iriterestsof clarity error conditions 
have been omitted. The capture of other signalling mes- 
sages, particularly" thos'e involved in modifying calls, 
could also be captured and used to update the service 
detail 'record with additional information and time 
'stanhfDs. It may also "be required to initiate further FSMs 
to mpnitor other aspects of the call. 

' 3'.' H.245 Control Channel FSM (see Figure 16) 

*|0094] This is initiated from the C^lf Signalling Mes- 
sage FSM and rhoiiitors all messages on the" H.245 
Control Channel' for' ihe duration of the call. The FSM is 
terminated by the detection of an endSessionCommand 

' message oh the H.245 Control Channel. Logical chan- 
nels are opened and closed using the openLogical- 
Channel and closeLogicalChannel messages. The FSM 
detects'the opening of a Channel, extracts the relevant 
data and initiates two new FSMs to monitor the forward 
and reverse Real Time Control Protocol (RTCP) con- 
nections (RS-FSMs - see item 4 below). A logical Chan- 
nel is uniquely identified by the Logical Channel Number 

* (LCN). This is used to identify the RS-FSMs to be ter- 



minated when the closeLogicalChannel messages are 
received. 

[0095] The main process paths are indicated in Figure 
16; however there are many more messages on the 
5 Control Channel which could be captured to provide ad- 
ditional information in the service detail record. 

4. RTCP Session FSM 

10 [0096] The RTCP connection provides detailed infor- 
matbn on the performance of the RTP connection that 
it controls. This can be captured as required to provide 
quality of sen/ice information iri the service detail record. 
TK6 BTP streanr) itself may be monitored at multiple 

15 points in its path to matke quality of service measure- 
ments which can be added to the service detail record. 

EXAMPLE 2 -Endpoints Communicating via a 
Gatekeeper 

20 

[0097] When a gatekeeper is involved the Call Signal- 
ling Channel may no longer be carried on the, well- 
known Transport Address; instead a dynamic TSAR 
identifier which the endpoint obtains from the gatekeep- 

-^5 er may be used. The FSM for this situation is shown in 
Figure 17. This process uses the ' information about 
gatekeepers and endpoints acquired during the gate- 
keepisr discovery process. The RAS Channel between 
all gatekeepers and endpoints is continuously, moni- 

so tored for control niessages. An Adnnission Request 
(AFiQ)'%l!owe'cl by ah Admission Confirmation (ACF) 
means that the ehdpoint has requ'ested to setup a call 
and has been atfdwed to do so t>y the gatekeeper. The 
Transport Address which will be used for the Call Sig- 

35 nailing Channel can be obtained fronn the Admission 
Confirmation message. A Call Signalling Message FSM 
is initiated to monitor the reliable connection for that 
Transport Address. The remainder of the processing 
proceeds in a similar manner to Example 1 . 

40 [0098] The example in Figure 17 shows the generic 
case of simply identifying the Call Signalling Channel. It 
Is straightforward to extend this to include the creation 
of the service detail record in response to an Adrhission 
Request message from the endpoint to the gatekeeper. 

45 This eriables the creation of service detail records which 
include information and time staimps taken from the call 
related rhessa'ges on the RAS Channel. It also enables 
the generation of sen/ice detail records in the case 
where an Admission Reject messagis is received iand no 

50 Call Signalling Channel is ever established. 

[0099] The presence of gatekeepers may also affect 
the call clearing process. Typically a disengage request 
(DRQ) message Is transferred between the endpoint 
and the gatekeeper as part of the call clearing process. 

55 [0100] The Call Reference Value (CRV), in cases 
where it Is implemented by vendors, can be used 
throughout the call as a unique identifier for all the mes- 
sages. 
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[0101] The processes described above can be split in 
nnany different ways between the probes and the other 
processors in the Distributed Management Infrastruc- 
ture. There are established methods for choosing how 
to distribute the processing; the Hewlett-Packard 
access/ architecture provides one example of how this 
may be achieved. 



Claims 

1. A method of generating generalised service detail 
records for communications carried over a packet 
network, comprising the steps of: 

acquiring packet network service data from 
packets carrying the communications; 
acquiring signalling data from a signalling pro- 
tocol to identify at least one of addressing, con- 
figuration, status and timing information for 
endpoints, gatekeepers and connections in- 
volved in a call; and 

combining said packet service data and said 
signalling data to generate service detail 
records. 

2. The method of claim 1 , wherein some or all of the 
data are captured by a passive monitoring system. 



3. The method of claim 1 or claim 2, wherein packet 
network service data are acquired from the protocol 
headers of the packets carrying the signalling data 
for the service. 

4. The method of any one of the preceding claims, in- 
cluding using the information identified from the sig- 
nalling data to identify the logical channels carrying 
the media streams, and capture some or ad of the 
packets on the logical channels in real-time at one 
or more points In the network. 

5. The method of claim 4, wherein captured data are 
used to measure the quality of service actually 
achieved by each channel. 

6. The method of claim 4, wherein captured data are 
used to provide secret access to the media stream 
for troubleshooting or surveillance purposes. 

7. The method of claim 6, wherein addressing infor- 
mation for the target user is used to select the cor- 
rect signalling packets, potentially in conjunction 
with data from a network discovery database. 

8. The method of any one of the preceding claims, in- 
cluding correlating the data from the packet network 
with data collected from a switched circuit network 
(such as a PSTN. ISDN or B-ISDN) to enhance the 
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generalised service detail records. 

9. The method of claim 8, including use of data col- 
lected from passive monitoring of a signalling net- 

5 work (e.g. SS7) or access signalling (e.g. ISDN, B- 
ISDN). 

10. The method of claim 8, including use of data col- 
lected from the switched circuit network for audio or 

^0 video quality. . 

11. The method of any one of the preceding claims, in- 
cluding using the generalised service detail records 
to bill. for the service, optionally taking into account 
the quality of service and usage data, arid optionally 
including tracking to see if customers have been ex- 
ceeding their agreed bandwidth constraints. 

12., The method of any one of the preceding claims, in- 
cluding using the generalised service detail records 
to detect potentially fraudulent service usage, per- 
„ foriTi network planning, perform marketing studies, 
perform network operations functions, modify the 
network configuration in real-time to achieve quality 
of service objectives, and/or perform customer care 
functions. , . 

13. A method of discovering the network confi g uration 
of the endpoints, gatekeepers and their relation- 

. ships, for a com nnunicat ions service carried by. a 
. . packet network,, by using a passive mpnitpripg sys- 
tem to capture the signalling messages involved in 
the configuration and negotiation of relationships, 
addressing and resource allocation, between end- 
points and gatekeepers. 

14. The method of claim 13, wherein the signalling mes- 
sages captured are gatekeeper request, gatekeep- 
er confirmation and gatekeeper reject messages. 

40 

16. The method of claim 14, wherein data are extracted 
from the captured signalling messages to identify at 
least one of the following types of infornnation: avail- 
able gatekeepers, alternative gatekeepers,, gate- 
45 Keepers rejecting request messages, endpoints 
which receive no response to request messages, 
and gatekeepers which are excessively slow to re- 
spond to requests. 

50 16. The method of claim 13, wherein the signalling mes- 
sages captured are endpoint registration request 
messages and associated registration confirmation 
and reject messages. 

55 17. The method of claim 1 6, wherein data are extracted 
from the captured signalling messages to identify at 
least one of the following types of information: rela- 
tionships between gatekeepers and endpoints, cor- 
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relations between Transport Addresses and Alias 
addresses, gatekeeper load balance, endpolnts re- 
ceiving no response to request messages, gate- 
keepers which are excessively slow to respond to 
requests, correlation between gatekeeper zones 5 
' and physical network topology, choice by endpolnts 
of gatekeepers with which to register, and rejections 
of registration requests. 

18. A method of generating generalised service detail io 
records for communications carried over a packet 
network, comprising the steps of: 

acquiring packet network service* data for the 
packets carrying the communications service; 
acquiring signalling data regarding at least one 
• of call control, registration, admissions, band- 
width managenrient, call status, address trans- 
lation and intelligent network services; 
•acquiring quality of service data for the service 
transmission level; and ' • 

combining said service data, said signalling da- 
ta and said quality of service data to generate 
generalised service detail records' 

19. The method of any one of the preceding claims, 
wherein the capture of packets is performed at mul- 
tiple points in real time, and then correlated in real- 

• ' time. - ' ' . . • 

"20. The method of any one of the preceding claims, 
' wherein the communications corhprise real-time 
' voice or audio, fax, Voice-messaging, real time vid- 
eo or multirfiedia communicatiohs. 

21. The method of any one of the preceding claims, 
wherein the packet network is an IP, frame relay or 
ATM network. • 

22. A method of monitoring a packet data sub-network 40 
or link, comprising the steps of: monitoring at a first 
location signalling messages to detect the exist- 
ence of a call; and monitoring at multiple other lo- 
cations to identify some or all packets associated 
with the call. 
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